The present invention relates to a program processing method and apparatus. The present invention is particularly effective in a case where a program developed without taking a data flow into consideration is employed to automatically produce a program of a data flow type by using a program code of the original program or in a case where there is created an input/output (I/O) program of a data flow structure of which I/O specifications are defined by message data.
Heretofore, the conventional software achieving a totally centralized control operation is executed in an environment which is insufficient with respect to the software expendability and maintenance. This has been an onerous hindrance when constructing a system.
In order to remove the problem, there has been known a distributed processing method adopting a plurality of information processing apparatuses connected to a shared or common transmission medium to accomplish a sequence of data processing steps in a distributed manner.
As mentioned above, in a case where a sequence of data processing steps of a job is achieved by a plurality of processors in a distributed fashion, there may be adopted a method in which one of the processors conducts a program execution control for the other processors. However, this method is attended with a disadvantage that a control program utilized to control the processors becomes quite complex, for example, due to complications in the scheduling operation of programs to be executed on the other processors. Moreover, there exists another difficulty that a failure in the control processor leads the overall system to a system down mode. In addition, due to the concentration of information on the control processors, the processing speed is lowered in the system.
As a method of solving the difficulties mentioned above, there has been known in the conventional technology a method, for example, described in the JP-A-56-146361 (1982). In this method, in an environment of a distributed system established in consideration of autonomy of the software, the program drive and execution are controlled in a manner associated with a data flow.
Namely, this method is a distributed processing method applicable to a plurality of processors in which sequences of data processing steps can be executed by the respective processors without using the supervision of the control processor. Namely, the processors interconnected with each other via a shared transmission medium are each loaded with a program which executes a sequence of the processing steps of a job in a distributed manner. In each processor, when data is received from the transmission path and a set of data necessary for an execution of a program are completely arranged therein, the program is to be initiated.
In the prior art, the method of controlling the program execution has been described, however, considerations have not been given to how to generate a program achieving an operation of a data flow type. Namely, the technical problem for the program development has not been solved.
That is, as described in the JP-A-57-146361 (1982), in order to implement a method of controlling the operations to drive and to execute a program in a manner related to a data flow in a distributed system environment prepared in consideration of the software autonomy, the program is inevitably created to accomplish an operation of a data flow type. Consequently, a programmer producing the program is required to give consideration to a method of generating a program running in relation to a data flow, not to a method of the accustomed program language. This has been a heavy burden on the programmer.
Moreover, one of the conventional program developing methods has been, for example, a flow oriented program developing method described in the JP-A-63106044 (1988). In this method, a program developer need recognize logic only in a flow chart to develop a program without paying attention to source, object, and load module files.
In this regard, when a program is to be developed in the conventional technology, I/O processing is not discriminated from application processing in program specifications. Namely, in a processing flow, such processing is produced, for example, by describing appropriate steps at a point where external data is required. Consequently, the program processing includes all processing procedures ranging from acquisition of the external data to an operation to load an external device with data resultant from processing. For attaining a complete program, the described program processing then undergoes program development including program debugging, compilation, linkage, and loading.
Namely, in the prior art, a shared table is adopted to communicate data between a plurality of program routines such that a data source side writes data in the shared table and then supplies a data destination side with a fact that the data has been written in the shared table together with a location (address) where the data has been written. 0n receiving the notification, the data destination side can obtain the data from the shared table. On the data receiving side, it is necessary to prepare, in addition to the inherent application program, a program to be used for the processing, for example, to read the data from the shared table and to identify the routine on the data source side.
As described above, according to the conventional technology, in order to minimize the processing procedures of a program, the program is structured as follows. In the program, all input data are not acquired at the same time, namely, portions of the input data are sequentially received to be checked. When the data portion is found to be wrong, the data acquisition is stopped at the point to terminate the processing. Consequently, the program repeatedly achieves a procedure in which a portion of input data is received to conduct with the data a portion of application processing to be accomplished by the program so as to write as output data a result of the partial application processing in an external device. For the program development processes such as the compilation, linkage, and loading of the program, it is assumed as a premise that input processing and output processing are to be integral with application processing.
In the program development processes, the external specifications (i.e. the design and internal specifications of input and output data) cannot be separated from the internal specifications (i.e. the design specification of the application processing). Consequently, even when inconsistency appears in the specifications, it is difficult to determine a location in which one of the internal and external specifications the inconsistency causes an implementation error. As a result, the program debug efficiency is deteriorated.